CAN and CAN FD Protocl Overview

Introduction

Summary

A common legacy automotive network architecture often includes one or more CAN 2.0 bus and one or more CAN bus with flexible data rate (CAN-FD). Although CAN 2.0 and CAN FD are extensions of the same standard, there is often a misconception that the two are not compatible. CAN FD allows for a different data length and the potential for faster bit rate than CAN 2.0; however, CAN FD and CAN 2.0 devices may be used in the same network. This document will be used as an introductory description of the protocol differences and compatibility for users who would like to gain a high-level understanding. For more detail about CAN 2.0 and CAN FD, ISO 11898-1 defines the data link layer, ISO 11898-2 defines the high-speed physical layer, and ISO 11898-3 defines the low-speed physical layer. Refer to ISOs released 2015 or later to ensure accurate CAN FD details are included.

Background

The CAN (Controller Area Networking) bus was defined in the late 1980s by Bosch, initially for use in automotive applications (CAN 2.0). In 2014, an enhancement to the spec (CAN FD) was developed to improve throughput. CAN is a multi-master protocol that uses a single terminated twisted pair cable. The maximum bit rate available is 1 Mbit/sec (CAN 2.0) and 12 Mbit/sec (CAN FD). The allowable cable run (length) depends on the bit rate, but typical maximum data rate achievable is 125 KBytes/sec (CAN 2.0) and 1.5 MBytes/sec (CAN FD) with a maximum latency for a high priority message less than 8 µsec at 1Mbit/sec.

CAN is attractive for automotive networks because of its high reliability due to noise immunity with extensive error checking. Nodes on the network are not assigned addresses; rather, the messages themselves have an identifier which also determines the message priority. Depending on the functionality, nodes transmit specific messages and watch for specific messages. No two nodes can transmit the same message identifier because this would violate priority rules. In general practice, no more than 64 nodes can be on a single bus, though theoretically there is no limit. The data to define message details is typically maintained in a calibration table within a subsection of the firmware which can be updated without requiring a full firmware update. The industry standard to test CAN messages/routing is to create DataBase CAN (DBC) files (Vector proprietary format) for each node on the network, but other industry or custom tools may also be used.

CAN 2.0, CAN FD Message Structure

The CAN protocol uses a modified version of the Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) technique used on Ethernet. Should two messages determine that they are both trying to send at the same time, instead of both backing off and re-trying later (as is done with Ethernet), the CAN physical circuitry (PHY) detects which message has the highest priority and the lower priority message gets delayed. This means that a high priority message will always get through. The detail of how this occurs is handled by the PHY, and is not applicable to this overview. It is only of interest to those designing controllers, but details can be found in ISO 11898.

The basic message structure, which is the same for both CAN 2.0 and CAN FD, is shown in Figure 1.

For CAN 2.0 all bits are sent at the speed setting for the bus up to 1MBits/sec with the following fields:

• Start of frame (SOF).
• Message Identifier (MID) where the Lower the value the Higher the priority of the message. The length is either 11 or 29 bits long depending on the standard being used (Standard or Extended).
• Remote Transmission Request follows MID. Always = 0 for this case; therefore omitted above.
• Control field which contains an EDL to differentiate between CAN 2.0 or FD transaction and a DLC to specify the number of bytes of data to follow (0-8 for 2.0).
• Data Field length 0 to 8 bytes for CAN 2.0.
• Cyclic Redundancy Check (CRC)
• Acknowledge field (ACK) is an empty slot which will be filled by every node that receives the frame. This does not acknowledge the data was received by the intended node, rather at least one node on the whole network received it.
• End of Frame (EOF).

For CAN FD all bits are sent at the speed setting for the bus up to 12MBit/sec with the following fields:

• Start of frame (SOF).
• Message Identifier (MID) where the Lower the value the Higher the priority of the message. The length is either 11 or 29 bits long depending on the standard being used.
• Control field which contains:
• an EDL to differentiate between CAN 2.0 or FD transaction
• a bit rate switch (BRS) where 0 = no change in bit rate for the data phase and 1 = change to the nominated higher bit rate
• a DLC to specify the number of bytes of data to follow (0-8, 12, 16, 20, 24, 32, 48 or 64)
• Cyclic Redundancy Check (CRC).
• Acknowledge field (ACK) is an empty slot which will be filled by every node that receives the frame. This does not acknowledge the data was received by the intended node, rather at least one node on the whole network received it.
• End of Frame (EOF).

Table 1 provides a comparison of these details between CAN 2.0 and CAN FD.

Message collision is avoided because the PHY on each node that transmits its MID looks on the bus to see what other nodes are seeing. If an MID is in conflict with a higher priority MID (lower number), the higher priority message bit will pull the signal down (a zero bit is called dominant) and the lower priority node will stop transmitting.

CAN is a very reliable system with multiple error checks:

• Stuffing error - a transmitting node inserts a high after five consecutive low bits (and a low after five consecutive high). A receiving node that detects violation will flag a bit stuffing error.
• Bit error - A transmitting node always reads back the message as it is sending. If it detects a different bit value on the bus than the one it sent, and the bit is not part of the arbitration field or in the acknowledgement field, an error is detected.
• CRC error - each receiving node checks CAN messages for CRC errors (different rules apply for CAN 2.0 and CAN FD).
• Frame error - There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Frame Error will be flagged.
• Acknowledgement Error - If a transmitter determines that a message has not been ACKed then an error is flagged inside the PHY registers.

Open Systems Interconnection (OSI) Model

The CAN specification standardizes its communication functions based on the OSI Model (maintained by the identification ISO/IEC 7498-1). The model is used in many networking protocol specifications and describes a networking system divided into layers. Each layer interacts directly only with the layer immediately beneath it, and provides facilities for the layer above it.

Table 2 describes the seven layers of the OSI model.

For most automotive CAN applications, the difference between using CAN 2.0 and CAN FD is only a concern at level four and down of the OSI model. Level three and down (media layers) are all typically handled by the PHY. This means all CAN CRCs, arbitration, ACKs, etc. are handled within the media layers. Because of this, the transport layer (layer four) is the only level which requires firmware changes to differentiate between CAN 2.0 and CAN FD.

These changes at the transport layer (layer four) only need to be made for components when all conditions in Figure 2 are met:

• A single device is connected to BOTH the CAN 2.0 bus AND the CAN FD bus; AND
• The device wants to communicate with another device which also is connected to BOTH the CAN 2.0 bus AND the CAN FD bus; AND
• The device wants to transmit (or have the option to transmit) the EXACT SAME data in BOTH CAN 2.0 and CAN FD format; AND
• The data for transmission in question is more than 8 bytes.

CAN Message Conversion

If there are unavoidable cases where identical data must be sent in both CAN 2.0 and CAN FD formats between two devices, some conversion at the transport layer (layer 4) will need to be created in the device firmware. If standard engineering practices (including the OSI model) are followed, applications and development in the other host layers (session, application, presentation) will be unaffected by whether a message is CAN 2.0 or CAN FD.

CAN 2.0 -> CAN FD

A CAN 2.0 message can be transmitted directly on a CAN FD bus without changes to the format since CAN FD is backward-compatible with CAN 2.0. It must be added to the CAN FD DBC file (for test cases) or CAN FD calibration table (for industry releases) with correct message structure, and the CAN FD PHY must be configured to CAN 2.0 mode on all FD nodes within the same bus. A CAN FD bus cannot support CAN 2.0 and CAN FD messages at the same time.

CAN FD -> CAN 2.0

A CAN FD message can be “converted” to CAN 2.0 with few changes if the message data is 8 bytes or less. It must be added to the CAN 2.0 DBC file (for test cases) or CAN FD calibration table (for industry releases) with correct message structure and timing.

Converting a CAN FD message when the message data is greater than 8 bytes is very unlikely aside from a test or simulation scenario. This is because with a larger data size in the message, there is no reason to separate the data and slow the message down. If, for some reason this is desired, interface repackaging is required and can be performed in firmware using Transport Protocol (ISO 15765-2). All CAN FD timeouts need to respect the CAN 2.0 calibration table.

In the case of converting messages for a test or simulation, such as when a CAN FD physical interface must be tested without a second CAN FD interface, it’s possible to reconstruct the message into several CAN 2.0 messages and create timing changes in the DBC files.

Conclusion

While there are some differences between CAN 2.0 and CAN FD, understanding where these differences affect development can help avoid complexity in network design. CAN FD supports CAN 2.0 without any changes to the 2.0 message structure. In this case, the CAN FD PHY must be configured to CAN 2.0 mode on all FD nodes on the bus. CAN FD will not support both 2.0 and FD message structure simultaneously.

In most cases, a network would never have a reason to convert a CAN FD message for transmission on a CAN 2.0 bus; however, it’s important to follow up to identify messages (if any) that need to be “mirrored” on CAN 2.0 and CAN FD buses. It’s also necessary to determine the speed at which CAN FD messages will be sent before determining whether any firmware changes are required.

There may be some test or simulation cases where it is necessary to test a CAN FD device’s interface or functionality without another FD node available. It is not complex to “fool” a CAN FD device into sending/receiving messages with a CAN 2.0 device via test software as long as CAN 2.0 speed limitations are considered.